fix: consider all resolvable dids in invites "public" #2900
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Daniel Bluhm <dbluhm@pm.me>
Signed-off-by: Daniel Bluhm <dbluhm@pm.me>
dbluhm
force-pushed
the
fix/connection-reuse-did-peer
branch
from
1b5ba5d
to
17ea7f5
Compare
ianco
approved these changes
Apr 17, 2024
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This solves an issue @ianco was seeing in connection reuse with did:peer:2/4.
There was a conflict between my expectations while working on did exchange 1.1 updates and what was implemented for connection reuse for did:peer; I was expecting
my_didandtheir_didto only be set by operations taken in the DID Exchange manager whereas connection reuse was using these values to transfer knowledge of the invitation DID. Ultimately, for the implementation in DID Exchange, I needmy_didandtheir_didto be unpopulated so we know we need to generate a new DID (which is generally what we want, a "pairwise" relationship). Theuse_didimplementation and the logic that prevents generation of a new DID rely onmy_didin particular.The compromise I've landed on is to consider any invitation DID as a "public" DID, from the perspective of the connection record. While peer DIDs are not technically public, they are resolvable and the rest of the logic surrounding public DIDs transfers well to this scenario.